Release 10.1A: OpenEdge Development:
Progress Dynamics Advanced Development


Defining logic in a single custom super procedure

The first example is for a window managing the Customer table using the customerfullo SDO. The examples use objects from other parts of the documentation. If you need some of the base objects, you can simply build them. If your objects have different names, just adjust accordingly.

Suppose you want to define a user interface condition so that if the customer’s credit limit does not exceed the balance by at least $5,000, the Balance field is highlighted to show this. This check must be made whenever a row of data is displayed in the viewer, and also when the Credit Limit or Balance field is modified.

In a static viewer, you could simply write a simple statement into a local override of the displayFields procedure, which is executed each time a row is displayed, as shown:

PROCEDURE displayFields: 
/*------------------------------------------------------------------------- 
  Purpose:     Super Override of displayFields 
  Parameters:  pcColValues AS CHARACTER 
  Notes:       Highlights the Balance if it's too close to CreditLimit. 
-------------------------------------------------------------------------*/ 
  DEFINE INPUT PARAMETER pcColValues AS CHARACTER NO-UNDO. 
  RUN SUPER( INPUT pcColValues). 
  DO WITH FRAME {&FRAME-NAME}: 
    IF DECIMAL(RowObject.CreditLimit:SCREEN-VALUE) -  
       DECIMAL(RowObject.Balance:SCREEN-VALUE) < 5000.00 THEN 
         RowObject.Balance:BGCOLOR = 14.  /* Highlight the field in yellow. */ 
  END. 
END PROCEDURE. 

Note that there are some complications to writing code like this, because the viewer does not actually have access to the database record, or even the RowObject temp-table record. Because it is strictly a thin client object, the field values are simply copied into the screen values of the fields on display, and copied from there back to the associated SDO on save. So your code must use the SCREEN-VALUE attribute of each field to get at its value and then convert it to the proper data type. Also, note how the code scopes the field references to the default viewer frame name, which is represented by the preprocessor &FRAME-NAME.

If you want this same code to be executed ON LEAVE OF the Balance and CreditLimit fields, you can define a UI trigger for those events in the AppBuilder and associate the same code with them. In that case, it makes sense to move the code itself into a separate procedure to call from both places.

This kind of code is not available to a dynamic Viewer because there is no place to write the code. So you have to move the code to a custom super procedure you associate with the Viewer instance. In this case, the fields such as RowObject.CreditLimit are not directly available to the compiler when it compiles your super procedure, so you cannot reference them. Instead, your code must access the fields with the client API, which again is an instance (a running copy) of the single procedure rydynviewv.w, which reads data for your specific Viewer out of the Progress Dynamics Repository and creates the Viewer for you at run time.


Copyright © 2005 Progress Software Corporation
www.progress.com
Voice: (781) 280-4000
Fax: (781) 280-4095